Track based play systems

ABSTRACT

Track based play systems are described which comprise a set of physical play pieces and an associated computer game. In an embodiment, a user may arrange some or all of the play pieces in the set to form a path. The computer game is arranged to infer a virtual model of the path defined by the user-created arrangement of the play pieces. The inference may be based on data communicated by one or more the play pieces to the game or based on data from a local sensing device such as a camera which views the relative positions of the play pieces. Having inferred the path, the game constrains a virtual or physical object to the path within the game play and renders a graphical user interface showing at least a portion of the path.

BACKGROUND

There are many ways that a user can interact with a computer game andtypically a user controls the game via a keyboard and mouse, gamescontroller (which may be handheld or detect body movement) or touchscreen, dependent upon the platform on which the game is being played(e.g. computer, games console or handheld device). A number of gameshave also been developed in which gameplay is enabled (or unlocked)through the use of physical character toys which are placed on a custombase connected to a games console. By placing different toys on thecustom base, different gameplay is enabled.

The embodiments described below are not limited to implementations whichsolve any or all of the disadvantages of known apparatus for interactingwith computer games.

SUMMARY

The following presents a simplified summary of the disclosure in orderto provide a basic understanding to the reader. This summary is not anextensive overview of the disclosure and it does not identifykey/critical elements or delineate the scope of the specification. Itssole purpose is to present a selection of concepts disclosed herein in asimplified form as a prelude to the more detailed description that ispresented later.

Track based play systems are described which comprise a set of physicalplay pieces and an associated computer game. In an embodiment, a usermay arrange some or all of the play pieces in the set to form a path.The computer game is arranged to infer a virtual model of the pathdefined by the user-created arrangement of the play pieces. Theinference may be based on data communicated by one or more the playpieces to the game or based on data from a local sensing device such asa camera which views the relative positions of the play pieces. Havinginferred the path, the game constrains a virtual or physical object tothe path within the game play and renders a graphical user interfaceshowing at least a portion of the path.

Many of the attendant features will be more readily appreciated as thesame becomes better understood by reference to the following detaileddescription considered in connection with the accompanying drawings.

DESCRIPTION OF THE DRAWINGS

The present description will be better understood from the followingdetailed description read in light of the accompanying drawings,wherein:

FIG. 1 shows schematic diagrams of two example play systems and aschematic diagram of an example arrangement of a subset of the physicalplay pieces;

FIG. 2 shows a flow diagram of an example method of operation of acomputer game;

FIG. 3 is a schematic diagram of an example active piece and a flowdiagram showing an example method of operation of an active piece;

FIG. 4 is a schematic diagram of another example active piece whichincorporates the game;

FIG. 5 shows schematic diagrams of example arrangements of physical playpieces;

FIG. 6 shows a flow diagram of another example method of operation of acomputer game;

FIG. 7 is a schematic diagram of two example physical play pieces whichform part of a set of physical play pieces;

FIG. 8 is a flow diagram of an example method of operation of a coreplay piece such as shown in FIG. 7;

FIG. 9 shows a schematic diagram of hardware which may be used toperform topology detection and a flow diagram of an example method ofusing the hardware; and

FIG. 10 illustrates an exemplary computing-based device in whichembodiments of the methods described herein may be implemented.

Like reference numerals are used to designate like parts in theaccompanying drawings.

DETAILED DESCRIPTION

The detailed description provided below in connection with the appendeddrawings is intended as a description of the present examples and is notintended to represent the only forms in which the present example may beconstructed or utilized. The description sets forth the functions of theexample and the sequence of steps for constructing and operating theexample. However, the same or equivalent functions and sequences may beaccomplished by different examples.

FIG. 1 shows schematic diagrams of two example play systems 101-102which each comprise a set of physical play pieces 103-104 and a computergame 106 and a schematic diagram of an example arrangement 105 of asubset of the physical play pieces 103-104. In both example play systems101-102, the game 106 uses a user's arrangement 105 of the plurality ofphysical play pieces 103-104 as an input and so the game 106 may bedescribed as being associated with the set of physical play pieces103-104. During game play, the arrangement 105 may remain the same or auser may dynamically re-arrange the physical play pieces to create newarrangements and/or modify an existing arrangement.

As described in more detail below, the individual physical play pieceswhich form the set may all be the same shape or may have differentshapes (as shown in FIG. 1) and the shapes of the pieces may be regularshapes (e.g. square or rectangular) or irregular in shape (e.g. as isthe case for many of the pieces shown in FIG. 1). The pieces may beshaped such that they are interlocking or can otherwise connect to eachother (e.g. via connectors on each piece). The connection between piecesmay provide a physical connection and/or an electrical connection. Invarious examples, the pieces may be shaped such that they can be buttedup to each other without any connecting mechanism joining the piecestogether. Where the physical play pieces are shaped so that they can bebutted up against each other or are interlocking, the play pieces withinthe set may be described as being compatible and may also be referred toas tiles. In further examples, the pieces may not be shaped so that theycan be placed close together and a user may arrange them as they choose.

In the first example play system 101 shown in FIG. 1, the physical playpieces 103 are active pieces in that each piece actively communicates(i.e. sends/receives data) with other pieces and/or the associated game106 to assist the game 106 to infer a shape of a path defined by thearrangement of the pieces and in various examples to infer a shape of apath defined by both the arrangement and the shape of the pieces (e.g.as in the case of the arrangement 105 shown in FIG. 1). In exampleswhere inference is based on both the arrangement and the shape of thepieces, the set of pieces comprises pieces having different shapes (e.g.as shown in FIG. 1). Active pieces are described in more detail belowwith reference to FIG. 3. The associated computer game 106 runs on acomputing device 108 which may be a desktop, laptop or tablet computer,a games console, a smart phone or any other computing device. In otherexamples, however, the computing device 108 may be integrated into oneof the play pieces 103 and this is described in more detail withreference to FIG. 4. In the example system 101 shown in FIG. 1, the game106 is stored in memory 110 in the computing device 108 and comprisesdevice-executable instructions which are executed by a processor 112.The game 106 receives data from the active pieces 103 via acommunication interface 113 in the computing device 108. It will beappreciated that the computing device 108 may also comprise additionalelements and the computing device 108 is described in more detail belowwith reference to FIG. 10.

In the second example play system 102 shown in FIG. 1, the physical playpieces 104 are passive in that they do not actively communicate witheach other or with the associated game. In the example system 102 shownin FIG. 1, the game 106 is stored in memory 110 in a computing device114 and comprises device-executable instructions which are executed by aprocessor 112. Instead of receiving communications from one or morepieces (as in example 101), the game 106 senses the arrangement of thepieces using a sensing device 116 in the computing device 114 on whichthe game runs. As described above, the computing device 114 may be adesktop, laptop or tablet computer, a games console, a smart phone orany other computing device. It will be appreciated that the computingdevice 108 may also comprise additional elements and the computingdevice 114 is described in more detail below with reference to FIG. 10.The sensing device 116 may, for example, be a camera and imagerecognition/analysis system. Although the sensing device 116 is shown aspart of the computing device 114, in other examples it may be part of aperipheral device connected to the computing device 114. In variousexamples, the sensing device 116 may be a Microsoft® Kinect®. Dependingon the sensing technology, the passive physical play pieces 104 may beconstructed to facilitate the job of sensing their arrangement. Forexample, for a depth-camera based system using infra-red light, thepieces may be (or may have parts that are) reflective in the infra-redspectrum. For visible light cameras, the pieces may include color orpattern combinations that are chosen to be easily recognized ordifferentiated from the background.

In a further example play system, the set of physical play pieces maycomprise one or more active pieces and one or more passive pieces. Insuch an example, the active play pieces may detect their own arrangement(or configuration, e.g. orientation, which other play pieces they areconnected or adjacent to, etc.) and also the arrangement of anyproximate passive pieces and then communicate with other pieces and/orthe game 106 to assist the game 106 to infer a shape of a path definedby the arrangement of all of the pieces.

The operation of the game 106, which may be referred to as an electronicgame, a video game or computer game (because it runs on a computingdevice 108, 114 and comprises device-executable instructions even thoughthat computing device may take any form), can be described withreference to FIG. 2. As shown in FIG. 2, the game 106 infers a virtualmodel of a path defined by an arrangement of physical play pieces (block206), where these pieces may, for example, be the pieces 103-104 shownin FIG. 1. Dependent upon whether the pieces are active (as shown inexample 101) or passive (as shown in example 102) or a combination ofactive and passive play pieces, the inference (in block 206) may bebased on configuration data received from one or more physical playpieces (block 202) and/or on sensing the arrangement of play pieces(block 204). Where the pieces are active, the configuration data may bereceived from each of the play pieces (in block 202) or alternativelythe configuration data may be collated by a subset of the play pieces(which in an extreme case may be a single play piece within the set) andthe game may then receive configuration data from the subset of the playpieces.

The virtual model of the path can be inferred (in block 206) from thephysical pieces in a number of ways depending on whether the pieces areactive or passive, how they are sensed, and whether the piecesthemselves constitute the path or whether the pieces constituteboundaries or waypoints that define the path implicitly (as described inmore detail below with reference to FIG. 5). For active pieces whichsense their interconnectivity, the shapes of the pieces and theinterconnectivity information (which may include information concerningthe sensed relative orientation of pieces as well as the identities ofneighbor pieces, where the orientation is not fixed due to jointsbetween the pieces being rigid) can be used to infer a real-worldtopology which can be directly mapped onto a virtual track pathfollowing a similar 2D or 3D layout. For passive pieces sensed through aremote sensing device 116, the sensor can determine the identity,location and relative orientation of the pieces which can feed into theabove inference process as well. Where the pieces form walls betweenpaths, the paths can be derived from the wall positions using a numberof methods. One such method is to “invert” the sensed paths, i.e. torender them onto a virtual image (e.g. in black on a white background),and then to use computer vision techniques to look for white lines thatremain, or to use a virtual robot which can only “walk” on white pixelsto virtually explore and hence generate a topological map of whichlocations can be reached from other locations.

Having inferred a virtual model of a path (in block 206), the gameconstrains the position of a virtual and/or physical object to that pathwithin the game play (blocks 208-210). In various examples, theconfiguration of at least a portion of the path (e.g. at least the partof the path where the object is currently located) and/or the objectwhich is constrained to the path are reflected within a graphical userinterface (GUI) of the game (block 212). In various examples, thiscomprises displaying a portion of the path, the object and/or a viewfrom the path within the GUI. In addition, or instead, the reflection ofthe path within the GUI may comprise enabling user inputs to affectmovement of an object along the path as part of the game play. This maybe directly (e.g. by linking a user input to a particular motion alongthe path within the gameplay such as “left button=go left along path”)or indirectly (where the object's actual motion is controlled by thegame engine but the user inputs higher-level commands such as “stayput”, “follow another object”, “search for another object”, etc.).

In examples where a virtual object is constrained to the path (in block208), the edges of the virtual path may be treated, within the gameplay, like barriers or walls that the virtual object cannot pass throughand various example game scenarios are described below. The motion ofthe virtual object along the path may be controlled by a physics enginewithin the game 106 and in various examples, the physics engine may alsocontrol the effect on the virtual object of hitting the edge of thevirtual path (e.g. the object may bounce back off the wall). In variousexamples, there may be a feedback mechanism on the physical play piecesthemselves (e.g. in the form of one or more LEDs) to indicate thecurrent position (and hence also the motion) of the virtual object onthe virtual path relative to the actual arrangement of the physicalpieces. Any feedback mechanism may, in addition or instead be used todisplay the position (or motion) of a virtual object which is controlledby the game (e.g. to show its position relative to a virtual objectcontrolled by the user or relative to a physical object constrained tothe path and controlled by the user).

In examples where the physical object is constrained to the path (inblock 210) this may be a result of the physical shape of the play piecesthemselves (e.g. the play pieces may have one or more grooves orindentations in their surface along which the physical object moves), aconstraining mechanism within the play pieces that is controlled by thegame (e.g. electromagnets within the pieces that attract the object andare switched on and off by the game) and/or virtual in-game effects(e.g. such that if the physical object is removed from the path itdisappears from within the virtual world depicted by the game). Thephysical object may be moved directly by the user (e.g. the user maypush the object along the track) or indirectly by the user (e.g. via thegame or other remote control device). Alternatively, the physical objectmay be controlled by the game without user input (e.g. it may be anautonomous object). When the game controls the physical object'smovement, the object can be constrained to follow the path byrestricting the control sequences to stay on the path. In variousexamples more subtle constraints may be used, whereby the game UI allowsthe user to control the movement of the object and leave the path, butif they do so, then in-game penalties occur (e.g. in a racing game, theobject moves slower), or modifications to the control system are made(e.g. the steering is altered slightly to tend to move the object backtowards the path).

There are many ways in which the GUI may reflect the configuration of atleast a portion of the inferred path to the user (in block 212) and invarious examples also display the object. In various examples the GUImay display a plan view (e.g. similar to a map) of the inferred pathand/or a view of a part of the path as if seen from the position of theobject (e.g. where the object is a vehicle, the view in the GUI may beas would be seen by an occupant of the vehicle). This may, for example,enable a user to appear (within the computer game) to be driving avehicle around a path they have created in their own living room, wherethe path is defined by active pieces or passive pieces. Where the pathis inferred based on passive pieces, the passive pieces may includeitems of furniture, cushions, etc. in the living room.

As described above, in various examples a user may re-arrange thephysical pieces to create modify the arrangement during game play. Thisre-arrangement may result in the method shown in FIG. 2 being repeated(e.g. the game will infer a new path and then reflect this in the GUIand constrain a physical/virtual object to the new path).

Although the arrangement of pieces 105 shown in FIG. 1 is of a closedpath, in various examples, a user may create a path which is not closed(e.g. it may have a start and a finish). In such examples, a user may beable to extend the path by removing parts of the arrangement (i.e.pieces from the set) which have already been traversed by thevirtual/physical object that is constrained to the path (e.g. byremoving parts from the start of the path) and placing the parts at theopposite end of the path (e.g. at the end of the path). In variousexamples the path may be inherently directional (i.e. the object whichtraverses the path may have to move in a predefined direction).

FIG. 3 is a schematic diagram of an example active piece 300 and a flowdiagram showing an example method of operation of an active piece. Theactive piece 300 comprises a processor 302, transmitter 304 and one ormore sensors 306. As shown in the flow diagram, the piece detects thearrangement of the piece using the one or more sensors 306 (block 310)and then transmits configuration data which describes the arrangement ofthe piece using the transmitter 304 (block 312). The configuration datamay be transmitted (in block 312) directly to the game or may betransmitted to another play piece. Where one play piece collectsconfiguration data for one or more other play pieces, it may receiveconfiguration data from other play pieces (block 314) prior totransmitting all the configuration data to the game (in block 312).Where the set of physical play pieces comprises a combination of activepieces and passive pieces, an active piece may detect the arrangement ofa proximate passive piece (block 316) prior to transmitting theconfiguration data to the game (in block 312).

The one or more sensors 306 detect the arrangement of the play piece 300(in block 310) and the arrangement which is detected may be an absoluteposition and/or orientation of the play piece (e.g. “at coordinate(x,y)” and/or “face B upwards”) or a relative position of the pieces(e.g. “next to piece X” or “between pieces A and B”) or a combination ofthe two (e.g. “next to piece X and face A upwards”). Examples of sensorswhich may be used include, but are not limited to, accelerometers,magnetometers, infra-red transceivers, color sensors, etc. Two playpieces 300 may also communicate with each other using a wired (e.g.1-Wire) or proximity-based wireless networking technology (e.g. RFID) todetermine their relative orientation. As described above, the one ormore sensors 306 may also detect the arrangement of a proximate passiveplay piece (in block 316), e.g. using RFID, magnetometers, color sensorsor other sensing technologies.

In some examples, the active piece 300 may further comprise a feedbackmechanism 307 (e.g. one or more LEDs) and a receiver 308. The feedbackmechanism 307 may be used to indicate the position of a virtual objecton the path defined by the arrangement of physical pieces. Consequently,an active piece 300 may receive a command (e.g. data) from the game 106via the receiver 308 (block 318) indicating a position of a virtualobject and may activate the feedback mechanism 307 to display theposition (block 320). The virtual object, the position of which isindicated by the feedback mechanism 307, may be a virtual object whichis controlled by the user within the game 106 or an autonomous objectcontrolled by the game 106. In other examples, the feedback mechanism307 may be arranged to move the physical object along the track (e.g.using motors and/or servoes and/or by providing control signals to acontrol mechanism within the physical object).

The transmitter 304 and/or receiver 308 in a play piece 300 may be awireless device and may for example use Bluetooth® Low Energy (BLE) orother short range wireless protocol (e.g. IEEE 802.15.4 or ANT+). Inother examples, the transmitter 304 and/or receiver 308 in a play piece300 may use a wired connection to the computing device 108. Where awired connection is used, the connection to the computing device 108 maybe provided by only one of the active pieces in the arrangement whichmay collect data from all the other active pieces in the arrangement fortransmission to the computing device 108. Use of a wired connection maybe useful where one or more active pieces have a relatively high powerconsumption (which would result in a short battery life if batterypowered) because the wired connection can also be used to provide powerto the play piece and, in various examples, to other play pieces in thearrangement. For example, if the physical play pieces move the physicalobject along the path using motors or servoes or if pieces incorporatedisplays or vibration motors to show where the virtual object is, etc.

FIG. 4 is a schematic diagram of another example active piece 400 whichincorporates the game 106. This active piece 400 may be part of a set ofphysical play pieces where the other active pieces in the set are asshown in FIG. 3 and described above. The set may only comprise activepieces (e.g. one piece 400 and multiple pieces 300) or may also compriseone or more passive pieces. As shown in FIG. 4, the active piececomprises a processor 112, memory 110 which stores the game 106, acommunication interface 113 and one or more sensors 306. The operationof this active piece can be described with reference to FIGS. 2 and 3.The active piece 400 receives configuration data from one or more otherphysical play pieces in the set (block 202) via the communicationinterface 113 and also detects its own arrangement (block 310) using theone or more sensors 306. In various examples, the active piece 400 mayalso detect the arrangement of a proximate passive piece (block 316)using the one or more sensors 306. From the detected arrangements andconfiguration data received, the game 106 infers a virtual model of apath defined by the arrangement of the play pieces (block 206) andconstrains a virtual/physical object to the path as part of the gameplay (block 208 and/or block 210).

In various examples the active piece 400 may further comprise a feedbackmechanism 307 which is controlled by the game 106 and the game maytransmit signals to other active pieces (via communication interface113) to control feedback mechanisms in other active pieces in thearrangement.

The game may also generate a GUI showing the virtual model of the path(or at least a part of the path) and the object constrained to the pathand this GUI may be rendered on a separate computing device. In anexample, a separate computing device may render the GUI within a webbrowser and this separate computing device may communicate with theactive piece 400 directly via the communication interface 113 or mayreceive the GUI data via an intermediary (e.g. from a web server whichcommunicates with the active piece 400). For example, the active piece400 may be connected to a cloud service which performs the graphicsprocessing to render complex game content which can be viewed in a webbrowser on the separate computing device. This means that the playpieces only have to sense and report low-level data about their relativeplacement. Alternatively, the play pieces may incorporate one activepiece that acts as a web server and generates the GUI via that webservice. Access to the web service (by the separate computing device)may be via an 802.11 wireless access point embedded in the active pieceor the active piece may connect to a shared network (e.g. a home WiFi™network, via transmitter 304). Discovery of the active play piece mayuse techniques such as uPnP or the active piece may have an NFCinterface which allows it to broadcast its current location on the homenetwork to nearby devices (e.g. by broadcasting a URL such ashttp://192.168.0.107/ where the home router assigned the play piecemaster that IP address).

There are many different ways in which the plurality of physical playpieces (whether active or passive) can define the shape of a path (asinferred by the associated game). A first example arrangement of pieces105 is shown in FIG. 1 and in this case a combination of the arrangementand shape of each of the pieces is used to infer the path. As can beseen in FIG. 1, in this example 105 the pieces themselves form the pathand in this example the pieces may be shaped to look like pieces of atrack (e.g. a railway track), path, road, etc. Another example of pieceswhich themselves form the track is shown in the first example 501 inFIG. 5. In this example 501, each of the pieces 510 resembles a portionof a tube or pipe and again a combination of the shape and arrangementof pieces form the path (e.g. as indicated by the arrows). In thisexample, the path may naturally be directional because a user willintuitively expect an object (or fluid) to fall (or flow) downwardsthrough the pieces.

In the next two examples 502-503 in FIG. 5, the pieces do not form thepath but instead define the boundaries (or edges) of the path (againindicated by arrows). In the first of these examples 502, the pieces 520form continuous walls which define the path (e.g. like a maze) and inthe second of these examples 503, the pieces 530 form an outline of thepath (e.g. like bollards or traffic cones/pylons) but do not necessarilytouch each other (i.e. there are gaps between pieces 530). A thresholdspacing between pieces 530 may be defined such that a gap between piecesthat is less than the threshold is not inferred as a gap in the boundaryof the path and a gap between the pieces that exceeds the threshold isinferred as a gap in the boundary of the path. The value of thethreshold may be fixed or variable and in various examples may bedependent on the object traversing the paths (e.g. a smaller object maybe able to pass through smaller gaps between pieces than a largerobject) and this may result in a game 106 inferring multiple paths (e.g.in block 206 of FIG. 2).

In the final example 504 in FIG. 5, the pieces 540 define the path(again indicated by arrows) by forming waypoints that the path goesthrough. In such an example, the pieces may be numbered to indicate theorder in which waypoints are traversed or this order may be input by auser or inferred by the game (e.g. according to the order in which thepieces are placed by the user).

In various examples, a user may be free to place the physical playpieces where they want and also to re-arrange the play pieces. In otherexamples, however, there may be restrictions which limit the positioningand/or order of placement of the play pieces. These restrictions may bea result of the physical shape of the play pieces (e.g. so that onlycertain play pieces can connect together or be placed abutting eachother) and/or may be a result of rules within the game (e.g. the gamemay specify that a blue edge to a piece may only be placed abutting ablue edge on another tile).

The sets of physical pieces and associated game may be used for manydifferent types of games and in various examples, the play pieces may beshaped according to the type of game. Various examples include:

-   -   vehicle based games where the pieces form a track, road, river        or rail and the physical/virtual object is a vehicle (e.g. car,        train, boat, rollercoaster car) which travels along the        track/road/river/rail    -   games where the pieces form pipes or tubes and the        physical/virtual object is a fluid which flows through the pipes        or tubes or an object (e.g. a marble or ball) which rolls along        inside the pipe or tube (a physics engine may control or        influence the motion of the fluid/object)    -   point-of-interest based games where physical pieces represent        waypoints such as planets (in a space-themed game) or castles        (in a historically-themed game) or other waypoints that the        virtual/physical object (e.g. a spacecraft, cart, etc.) can move        between. In this case, the path may be defined by other pieces        (in addition to the pieces representing waypoints), or the path        may be implicit, in that it is a direct route between waypoints.        In the latter case the path may be constrained by the game or        environment (rather than just being a straight line between        waypoints), e.g. there may be a maximum and/or minimum path        length between waypoints that is pre-defined. In another        example, the user may unlock a path between waypoints through        gameplay. In this case, projectors or other output technology        may be mounted on either the physical pieces, the computing        device hosting the associated game, or a third device, in order        to illustrate the paths and the activity on the paths in the        real world.

FIG. 2 (described above) shows a flow diagram of a method of operationof the game 106. Further operation of the game 106 (e.g. the GUI and/orthe game play itself) is affected by the inferred path (from block 206)and may also be affected by which particular physical play pieces areused to form the path and/or how the user interacts with the physicalplay pieces and any physical object which is constrained to the path. Invarious examples, user interaction with one or more play pieces or thephysical object translates into inputs to the game and the translation(from user interaction to game input) may be performed within a playpiece, physical object and/or within the game. The game inputs (andhence the user interactions) affect the operation of the game. Asdescribed above, a user may push or otherwise move a physical objectdirectly or may remotely control the object (e.g. via the game or otherremote control device). In further examples, the object may be powered(e.g. it may comprise a motor) and so may be autonomous or controlled bythe game 106 (e.g. it may be controlled by the feedback mechanism 307within an active piece).

As well as responding to the user's arrangement of play pieces (byinferring the path in block 206 and representing it within the game inblock 212) (and in various example also interactions with the physicalobject and/or play pieces) in a style of game play which may bedescribed as non-directed (because the game does not force or suggestany particular interaction with the play pieces and any physical objectconstrained to the path), the game 106 may also provide directed gameplay, as shown in FIG. 6.

In the directed game play, the game 106 presents goals or objectives tothe user (who might also be referred to as a player) within the game 106(block 604) where those goals/objectives require the player to interactwith the physical pieces and/or a physical object (where there is one)in order to further progress within the game 106, i.e. the user cannotachieve the goal/objective without interacting with the physical piecesand/or a physical object. For example, a user may need to rearrange thephysical play pieces to create a different shape of path (e.g. to reacha target location which may be a real or virtual location), move thephysical object along the path in some way (e.g. in the form of a race,to beat other virtual objects which are autonomously controlled by thegame), etc. In order to determine whether the objective has been met,the game 106 may receive configuration data from one or more physicalpieces (block 202), sense an arrangement (or change in arrangement) of aplurality of physical play pieces (block 204), receive data from aphysical object constrained to the path (block 606) or sense a location(or position along the path) of a physical object (block 608).

In examples where the game 106 receives configuration data from one ormore physical pieces (in block 202) or senses an arrangement (or changein arrangement) of a plurality of physical play pieces (in block 204),the game 106 then infers a new (or updated) version of a path from thisdata (block 206), as described above with reference to FIG. 2.

The game 106 then modifies the game play (block 610) dependent uponwhether the objective (set in block 604) has been met or not. By meetingthe objective, the user may be able to progress to a new level, achievea higher score, win a contest, unlock additional features (e.g. hiddenfeatures, mini-games, new levels, etc.) within the game 106, get an“achievement” awarded to them, assist other players in cooperativemultiplayer scenarios, play against other players in competitivemultiplayer scenarios, etc.

The progression which is achieved through the interaction with physicalplay pieces and/or physical object (and hence achieving the objectiveset) may be linear progression (e.g. progression to the next level) ormay be non-linear progression which results in an enhancement to thegame play. For example, the interaction may unlock some optional contente.g. a new avatar for the virtual vehicle which is not required tocomplete the main storyline of the game.

The directed game play may be explicit, in that the goals/objectives andthe corresponding need to interact with the physical play pieces and/orphysical object are clearly communicated to the user (e.g. throughmessages within the graphical user interface, GUI). Alternatively, thegoals/objectives and/or the need to interact with the physical playpieces and/or physical object may be implicit, in that thegoals/objectives or required arrangement of physical play pieces and/orphysical object are known to the game but are not communicated to theuser and must be discovered by the user. The use of implicit directedgame play adds further challenges to the user and enhances the userexperience.

The objectives which are presented to the user (in block 604) may bepre-defined and stored within the game software. Alternatively they maybe generated dynamically (block 602). In various examples, they may begenerated based at least in part on the information received from thephysical play pieces (in block 202 or 204 of FIG. 2), e.g. they may bedependent on the current arrangement of physical play pieces. In variousexamples, the objective which is set may be generated based on theuser's history (e.g. past performance) within the game or based on anyother characteristics of the user or information about the user. Datadetailing the user's history may, for example, be stored by the gameitself or alternatively may be stored on a remote server and accessed bythe game. By tailoring the objectives to be specific to a user, thisenhances the overall user experience within the game. In examples wherethe objectives are dynamically generated (in block 602), this maycomprise one or more of: choosing an objective or goal from apre-existing list of possible objectives/goals (e.g. based on acharacteristic of the user or another factor described above), creatingan objective/goal based on random factors and using existing gameplay todate to influence the choice/creation of objective/goal.

In various examples, the objective presented to the user (in block 604)may be time-based (e.g. complete the path within a defined time period),location based (e.g. create and/or traverse a path to a definedlocation, which may be real or virtual) and/or competitive (e.g. againstother users or autonomous objects within the game). In an example, theobjective may require the real/virtual object to traverse all parts ofthe path and stay ahead of an autonomous virtual object. In anotherexample, the object may require a user to modify the arrangement ofphysical pieces so that the object which is constrained to the path canreach a particular location in the real world (e.g. to reach the sofa inthe living room where the user is playing the game) or the virtualworld.

Although FIG. 6 shows directed game play which involves the playerphysical interacting with the physical pieces and/or physical object, invarious examples, the game may also involve virtual game play. Thevirtual game play may involve directed game play which relates tovirtual game play in addition to the directed play requiring physicalgame play to meet an objective set.

FIG. 7 is a schematic diagram of two example physical play pieces whichform part of a set of physical play pieces. FIG. 7 shows a core physicalplay piece 702 and a peripheral physical play piece 704. A set ofphysical play pieces may comprise one or more core play pieces 702 and aplurality of peripheral play pieces 704. The terms ‘core’ and‘peripheral’ in relation to play pieces are separate from the terms‘passive’ and ‘active’ which are described above. Whilst all core playpieces are also active play pieces, a peripheral piece may be an activeor a passive play piece.

The core play piece 702 comprises a battery 706, a wirelesscommunications module 708, a processor 710 and one or more connectors712. The battery 706 provides power to components within the core (suchas processor 710 and wireless communications module 708) and also tosome/all of the peripheral play pieces 704 via the connectors 712. Thewireless communications module 708 enables the core play piece 702 tocommunicate with a computing device running the game 106. Any suitablewireless technology may be used (e.g. Bluetooth®, BLE, WiFi™ or WiFi™Direct, Near Field Communication (NFC), 802.15.4, etc.). The wirelesscommunications module 708 may communicate directly with the computingdevice 108 (as shown in FIG. 1) running the game 106 or may communicatevia a network (e.g. a home network or the internet) or intermediarydevice (e.g. a wireless access point). The connectors 712 physicallyattach the peripheral play pieces 704 to the core play piece 702 and mayalso pass data and power between play pieces.

The processor 710 within the core play piece 702 is arranged to collectthe IDs (which may be a unique ID or an ID shared with otheridentical-looking play pieces, e.g. an ID for a particular shape or typeof play piece) of each of the play pieces connected together (and hencewhich form the path that will be inferred by the game 106). Theprocessor 710 may be a microprocessor, controller or any other suitabletype of processor for processing computer executable instructions tocontrol the operation of the core play piece in order to collect the IDsof connected play pieces. Core and peripheral play pieces may beconnected together in any way. The play piece IDs (which may justidentify a piece type, rather than uniquely identifying a play piece)may be collected from each of the connected play pieces directly (e.g.via a bus) or each play piece may collect information on its neighborswith the core play piece aggregating the data provided by its directneighbor play pieces. In various examples, these play piece IDs may becollected via the data connection provided by the connectors 712 and inother examples, another means may be used (e.g. NFC, QR codes orcomputer vision). Where other means are used, the core play piece 702may comprise additional hardware/software such as an NFC reader moduleor a camera or other image sensor to collect the play piece IDs of allthe connected play pieces. In addition to collecting the play piece IDsof the connected play pieces (e.g. to generate a set or list ofconnected play pieces), the core play piece may detect the topology ofthe arrangement of play pieces.

Each peripheral play piece 704 comprises one or more connectors 712, 714to physically attach the play piece to another play piece to form thepath. The peripheral play piece 704 further comprises electricalconnections 724 (e.g. in the form of a bus comprising 2 wires, data andground) between the two connectors 712, 714.

Each peripheral play piece 704 also comprises a storage element 716which stores an identifier (ID) for the peripheral play piece (which maybe referred to as the play piece ID) and which may identify the type(e.g. shape) of the piece or may uniquely identify the play piece. Thestorage element 716 may comprise additional data, such as the shapeand/or appearance of the play piece, locations of any connection points,mechanical compatibility details for connection points (e.g. detailingwhich other piece types can be connected to), other information used tohelp sense topology (e.g. color pattern), game play information (e.g. isthe virtual/physical object on the piece, so that this can be used insubsequent game play) etc. This additional data may be used by the game106 when inferring the path formed by an arrangement of physical pieces(e.g. in block 206 of FIG. 2) and/or in reflecting (e.g. rendering) atleast a portion of the path in a GUI (e.g. in block 212 of FIG. 2). Thestorage element 716 may comprise memory or any other form of storagedevice. In the example shown in FIG. 7, the storage element 716 whichstores the play piece ID is actually within the housing of the connector714; however, in other examples it may be separate from the connector.In various examples, a peripheral play piece 704 may also comprise aprocessor (not shown in FIG. 7) and this too may be within the housingof the connector 714 or separate from the connector. In variousexamples, a peripheral play piece 704 may also comprise a battery (notshown in FIG. 7) and this may provide power to electronics within theperipheral play piece 704 and/or to neighboring play pieces (which maybe peripheral or core play pieces). In this way, if an arrangement ofplay pieces requires more power than can be provided by the battery 706in the core play piece 702, additional power can be provided by abattery in a peripheral play piece 704.

Although not shown in FIG. 7, a core play piece 702 may also comprise astorage element which stores an identifier for the play piece. As withthe peripheral play piece, the storage element may comprise memory orany other form of storage device. The storage element which stores theplay piece ID may be within a connector 712, the wireless module 708 ormay be a separate entity within the core play piece 702.

It will be appreciated that the play pieces 702, 704 shown in FIG. 7 maycomprise additional elements not shown in FIG. 7. It will further beappreciated that although FIG. 7 shows the modules of being square orrectangular, each of the play pieces can have any physical form factor(e.g. any shape of external housing) which is compatible with the otherplay pieces (i.e. each play piece is shaped such that it can connect toat least one other play piece, without the outer housing clashing).

In various examples, a play piece (which may be a peripheral play piece704 or a core play piece 702) may comprise one or more sensors,actuators and/or displays that are controlled by and/or provide data tothe processor 710 within the core play piece 702. Examples of sensorsthat may be used include: temperature sensors, vibration sensors,accelerometers, tilt sensors, gyroscopic sensors, rotation sensors,magnetometers, proximity sensors (active/passive infrared orultrasonic), sound sensors, light sensors, etc. Examples of actuatorsthat may be used include: electromagnets, motors, servos, vibrationunits, solenoids, speakers, etc. Examples of displays that may be usedinclude one or more LEDs, a small LCD display, an c-ink display, etc.Where a play piece comprises a sensor, the sensor data may becommunicated by the core play piece 702 to the game 106.

FIG. 8 is a flow diagram of an example method of operation of a coreplay piece 702, such as shown in FIG. 7. The core play piece 702collects the IDs of the connected play pieces (block 804) andcommunicates play piece data to the game 106 (block 806) via thewireless module 708. In some examples the core play piece 702 maycollect a list of IDs (which may or may not include its own ID). Thetopology determination (in block 806) may be performed at the same timeas collecting the IDs (in block 804) or may be performed separately.

The topology determination (in block 806) may use any suitable method.In various examples, each connector 712, 714 in a play piece 702, 704may comprise hardware logic (such as an electronic switch) to enable theprocessor 710 within the core play piece 702 to dissect the bus (i.e.the electrical connections connecting all the play pieces)programmatically. This can be described with reference to FIG. 9. FIG. 9shows three play pieces 901-903, which may all be peripheral playpieces, connected to a 2-wire bus comprising a data line 904 and ground906. Hardware logic 908 (which includes the storage device holding theplay piece ID and may comprise a processor or other logic elements)within each play piece (e.g. within each connector 712, 714 in a playpiece) connects between the two lines 904, 906 and a protocol such asthe 1-Wire™ system may be used by the core play piece to communicatewith each of the play pieces 901-903. In order that the core play piececan dissect the bus programmatically, each connector comprises hardwarelogic 910 which can be controlled by the core play piece and used todissect the bus (e.g. by breaking the connectivity of the data line904).

In the example shown in FIG. 9, the core play piece may first cause thehardware logic 910 in all play pieces to break the connectivity of playpieces (block 92). This may alternatively be described as dissecting thebus and may be achieved in the example of FIG. 9 by opening the switch910 to break the connectivity in the data line 904. The core play piecemay then collect the IDs of all connected play pieces (block 94), whichin this case would only identify the ID of the first play piece 901 asthe other play pieces are not currently electrically connected to thecore play piece and this may be used to update topology informationabout the coherent physical whole object (block 96). The core play piecemay then cause the hardware logic 910 within the identified first playpiece 901 to reconnect the bus (block 98 e.g. by closing its switch) andthe core play piece may then repeat the ID collection operation (inblock 94). This second iteration would identify two IDs—the IDs of thefirst two play pieces 901, 902, such that the core play piece now knowsthat the second play piece 902 is connected to the first play piece 901(and the topology is updated accordingly in block 96). This method maythen be repeated to explore the full topology.

In order that the core play piece knows when it has identified therelative position of all the connected play pieces, the core may first(prior to causing the bus to be dissected) detect the IDs of all theconnected play pieces (block 91, e.g. when the bus is fully connected)and then proceed with the iterative discovery process until all detectedIDs have been discovered. An example method of operation of the coreplay piece which uses this is described below.

In a first detection step (block 91) the core play piece detects all theconnected play pieces, which in the example of FIG. 9 comprises threeplay pieces 901-903. It may then cause the bus to be dissected by eachof the play pieces (block 92). In a second detection step (block 94),the core play piece will now only detect the first play piece 901 so cangenerate the start of the topology as “core—play piece 901” (block 96).The core play piece may then check whether all play pieces have beenincluded within the topology (block 97) and in this case play pieces 902and 903 are missing (‘No’ in block 97). The core play piece may theninstruct detected play piece 901 to re-connect the bus. In fact, thecore can instruct all connected play pieces to reconnect the bus (block98). In a third detection step (block 94) the core play piece will nowdetect two play pieces 901, 902 and so can extend the topology to“core—play piece 901—play piece 902” (block 96). The core play piece maythen check whether all play pieces have been included within thetopology and in this case play piece 903 is missing (‘No’ in block 97).The core play piece may then instruct detected play piece 902 (or allconnected play pieces) to re-connect the bus (block 98) beforeperforming a fourth detection step. In this fourth detection step (block94) the core play piece will detect all three play pieces 901-903 and socan extend the topology further to “core—play piece 901—play piece902—play piece 903” (block 96). The core play piece may then checkwhether all play pieces have been included within the topology and inthis case all play pieces have been included (‘Yes’ in block 97) and sothe detection can stop (block 99).

Referring back to FIG. 8, the play piece data which is communicated tothe interactive software experience (in block 808) comprises the playpiece IDs (from block 804, or block 91 or 94 of FIG. 9 and which mayalso include the play piece ID of the core play piece 702) and may alsocomprise topology information (from block 806 or block 96 of FIG. 9). Inother examples, the play piece data may be an aggregated form of theplay piece IDs, rather than the raw IDs themselves. As described above,the data which is communicated to the game 106 enables the game to infera path (in block 206 of FIG. 2).

Some or all of the methods shown in FIGS. 8 and 9 may be repeatedperiodically. For example, a core play piece may regularly perform acollection of all play piece IDs (e.g. as in blocks 804 and 91) in orderto determine if a user has re-arranged the play pieces (e.g. byremoving/adding/replacing a play piece). In other examples, detection ofre-arrangement may be performed in another way (e.g. a peripheral playpiece may signal to the core when it has been attached, or the core playpiece might explicitly poll for play pieces by their ID or a subsetthereof, to either sense disconnection or connection).

When a user re-arranges the play pieces (e.g. by removing or adding anew play piece), it may not be necessary to perform a full topologyanalysis (e.g. as shown in FIG. 9) as the core play piece may know thata play piece that has been removed and may first check whether the newplay piece has been added in place of the removed play piece. This may,for example, involve performing only selective dissection of the bus. Inother examples, the full topology analysis may be performed.

In addition to collecting the play piece IDs and communicating them tothe game (in blocks 804-808), the core play piece may additionallyperform one or more additional functions. As shown in FIG. 8, the coreplay piece may provide power to a peripheral play piece (block 802).This power may be provided via the connector 712 and may use anelectrical contact within the connector or alternatively may useinductive (non-contact) charging methods with the connector 712 (andcorresponding connector 714 in the peripheral play piece) comprising aninductive coil.

Where a peripheral play piece 704 or the core play piece 702 comprisesone or more sensors, the core play piece 702 collects the sensor data(block 810) and communicates this data to the game 106 (block 812). Asdescribed above with reference to the IDs, the data which iscommunicated to the game 106 (e.g. via wireless module 708) may be theraw sensor data or an aggregated or processed form of the sensor data.

In various examples, the core play piece 702 may receive commands fromthe game (block 814), for example where a play piece (core/peripheral)comprises an actuator or display. In response to receiving such acommand, it may be processed within the core play piece (e.g. where thecore play piece comprises an actuator/display) or may be passed to aconnected play piece (block 816), e.g. to a play piece identified by itsID within the received command. In various examples, actuators may beused to constrain a physical object to a path formed by the play piecesand inferred by the game 106.

In various examples, such as the example shown in FIG. 8, each connector712, 714 comprises two electrical paths (e.g. ground and data). In otherexamples, the connectors 712, 714 may provide more than two electricalpaths.

FIG. 10 illustrates various components of an exemplary computing-baseddevice 1000 which may be implemented as any form of a computing and/orelectronic device, and in which embodiments of the methods describedherein may be implemented. This computing based device 1000 may, forexample, be the computing device 108, 114 shown in FIG. 1 or an activeplay piece 300, 400 such as shown in FIGS. 3 and 4.

Computing-based device 1000 comprises one or more processors 1002 whichmay be microprocessors, controllers or any other suitable type ofprocessors for processing computer executable instructions to controlthe operation of the device in order to perform the methods describedherein (e.g. infer a path and present at least a part of the path in aGUI). In some examples, for example where a system on a chiparchitecture is used, the processors 1000 may include one or more fixedfunction blocks (also referred to as accelerators) which implement apart of the method of path inference in hardware (rather than softwareor firmware).

Alternatively, or in addition, the functionality described herein can beperformed, at least in part, by one or more hardware logic components.For example, and without limitation, illustrative types of hardwarelogic components that can be used include Field-programmable Gate Arrays(FPGAs), Program-specific Integrated Circuits (ASICs), Program-specificStandard Products (ASSPs), System-on-a-chip systems (SOCs), ComplexProgrammable Logic Devices (CPLDs).

Platform software comprising an operating system 1004 or any othersuitable platform software may be provided at the computing-based deviceto enable application software, such as a game 106 to be executed on thedevice. As shown in FIG. 10, the game 106 may comprise one or moremodules, such as a path inference engine 1006 arranged to infer a path(e.g. as in block 202), a GUI generation engine 1008 arranged togenerate the GUI for the game play, including at least a part of theinferred path (e.g. as in block 212 of FIG. 2) and an objectivegeneration engine 1010 to generate objectives for directed game play(e.g. as in block 602 of FIG. 6).

The computer executable instructions may be provided using anycomputer-readable media that is accessible by computing based device1000. Computer-readable media may include, for example, computer storagemedia such as memory 1012 and communications media. Computer storagemedia, such as memory 1012, includes volatile and non-volatile,removable and non-removable media implemented in any method ortechnology for storage of information such as computer readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM,flash memory or other memory technology, CD-ROM, digital versatile disks(DVD) or other optical storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othernon-transmission medium that can be used to store information for accessby a computing device. In contrast, communication media may embodycomputer readable instructions, data structures, program modules, orother data in a modulated data signal, such as a carrier wave, or othertransport mechanism. As defined herein, computer storage media does notinclude communication media. Therefore, a computer storage medium shouldnot be interpreted to be a propagating signal per se. Propagated signalsmay be present in a computer storage media, but propagated signals perse are not examples of computer storage media. Although the computerstorage media (memory 1012) is shown within the computing-based device1000 it will be appreciated that the storage may be distributed orlocated remotely and accessed via a network or other communication link(e.g. using communication interface 1014).

The communication interface 1014 may be arranged to receive data fromone or more physical play pieces and may comprise a wireless transmitterand/or wireless receiver. In various examples the communicationinterface 1014 receives data from the physical play pieces directly andin other examples, the communication interface 1014 may receive datafrom the play pieces via an intermediary device. In examples where theplay pieces comprise a feedback mechanism (e.g. LEDs arranged to show alocation of a virtual object constrained to the inferred path) thecommunication interface 1014 may also be arranged to transmit data (e.g.commands) to one or more physical play pieces.

The computing-based device 1000 may also comprise an input/outputcontroller 1016. The input/output controller may be arranged to outputdisplay information (e.g. the GUI) to a display device 1018 which may beseparate from or integral to the computing-based device 1000. Theinput/output controller 1016 may also be arranged to receive and processinput from one or more devices, such sensors 1020 or a sensing module1022 (which may be internal or external to the computing based device1000) or a user input device 1024 (e.g. a mouse, keyboard, camera,microphone or other sensor). In some examples the user input device 1024may detect voice input, user gestures or other user actions and mayprovide a natural user interface (NUI). This user input may be used tofurther control game play. In an embodiment the display device 1018 mayalso act as the user input device 1024 if it is a touch sensitivedisplay device. The input/output controller 1016 may also output data todevices other than the display device, e.g. a locally connected printingdevice (not shown in FIG. 10).

Any of the input/output controller 1016, display device 1018 and theuser input device 1024 may comprise NUI technology which enables a userto interact with the computing-based device in a natural manner, freefrom artificial constraints imposed by input devices such as mice,keyboards, remote controls and the like. Examples of NUI technology thatmay be provided include but are not limited to those relying on voiceand/or speech recognition, touch and/or stylus recognition (touchsensitive displays), gesture recognition both on screen and adjacent tothe screen, air gestures, head and eye tracking, voice and speech,vision, touch, gestures, and machine intelligence. Other examples of NUItechnology that may be used include intention and goal understandingsystems, motion gesture detection systems using depth cameras (such asstereoscopic camera systems, infrared camera systems, RGB camera systemsand combinations of these), motion gesture detection usingaccelerometers/gyroscopes, facial recognition, 3D displays, head, eyeand gaze tracking, immersive augmented reality and virtual realitysystems and technologies for sensing brain activity using electric fieldsensing electrodes (EEG and related methods).

Although the present examples are described and illustrated herein asbeing implemented in a play system (comprising a set of physical playpieces and an associated game) as shown in FIGS. 1, 3 and 4, the systemsdescribed are provided as examples and not limitations. As those skilledin the art will appreciate, the present examples are suitable forapplication in a variety of different types of play systems.

Many of the examples described above involve physical game play by auser with a physical object which is constrained to the inferred path.It will be appreciated, however, that game play may involve acombination of some physical game play and some virtual game play.

The term ‘computer’ or ‘computing-based device’ is used herein to referto any device with processing capability such that it can executeinstructions. Those skilled in the art will realize that such processingcapabilities are incorporated into many different devices and thereforethe terms ‘computer’ and ‘computing-based device’ each include PCs,servers, mobile telephones (including smart phones), tablet computers,set-top boxes, media players, games consoles, personal digitalassistants and many other devices.

The methods described herein may be performed by software in machinereadable form on a tangible storage medium e.g. in the form of acomputer program comprising computer program code means adapted toperform all the steps of any of the methods described herein when theprogram is run on a computer and where the computer program may beembodied on a computer readable medium. Examples of tangible storagemedia include computer storage devices comprising computer-readablemedia such as disks, thumb drives, memory etc. and do not includepropagated signals. Propagated signals may be present in a tangiblestorage media, but propagated signals per se are not examples oftangible storage media. The software can be suitable for execution on aparallel processor or a serial processor such that the method steps maybe carried out in any suitable order, or simultaneously.

This acknowledges that software can be a valuable, separately tradablecommodity. It is intended to encompass software, which runs on orcontrols “dumb” or standard hardware, to carry out the desiredfunctions. It is also intended to encompass software which “describes”or defines the configuration of hardware, such as HDL (hardwaredescription language) software, as is used for designing silicon chips,or for configuring universal programmable chips, to carry out desiredfunctions.

Those skilled in the art will realize that storage devices utilized tostore program instructions can be distributed across a network. Forexample, a remote computer may store an example of the process describedas software. A local or terminal computer may access the remote computerand download a part or all of the software to run the program.Alternatively, the local computer may download pieces of the software asneeded, or execute some software instructions at the local terminal andsome at the remote computer (or computer network). Those skilled in theart will also realize that by utilizing conventional techniques known tothose skilled in the art that all, or a portion of the softwareinstructions may be carried out by a dedicated circuit, such as a DSP,programmable logic array, or the like.

Any range or device value given herein may be extended or alteredwithout losing the effect sought, as will be apparent to the skilledperson.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

It will be understood that the benefits and advantages described abovemay relate to one embodiment or may relate to several embodiments. Theembodiments are not limited to those that solve any or all of the statedproblems or those that have any or all of the stated benefits andadvantages. It will further be understood that reference to ‘an’ itemrefers to one or more of those items.

The steps of the methods described herein may be carried out in anysuitable order, or simultaneously where appropriate. Additionally,individual blocks may be deleted from any of the methods withoutdeparting from the spirit and scope of the subject matter describedherein. Aspects of any of the examples described above may be combinedwith aspects of any of the other examples described to form furtherexamples without losing the effect sought.

The term ‘comprising’ is used herein to mean including the method blocksor elements identified, but that such blocks or elements do not comprisean exclusive list and a method or apparatus may contain additionalblocks or elements.

The term ‘subset’ is used herein to refer to a proper subset such that asubset of a set does not comprise all the elements of the set (i.e. atleast one of the elements of the set is missing from the subset).

It will be understood that the above description is given by way ofexample only and that various modifications may be made by those skilledin the art. The above specification, examples and data provide acomplete description of the structure and use of exemplary embodiments.Although various embodiments have been described above with a certaindegree of particularity, or with reference to one or more individualembodiments, those skilled in the art could make numerous alterations tothe disclosed embodiments without departing from the spirit or scope ofthis specification.

The invention claimed is:
 1. A set comprising: a computer game; aplurality of passive physical play pieces, wherein the passive physicalplay pieces in the set are not configured to send or receive data withother physical play pieces or the computer game; and a plurality ofactive physical play pieces, wherein at least one of the plurality ofactive physical play pieces in the set comprises one or more sensorsconfigured to detect an arrangement of a proximate passive physical playpiece and is configured to actively communicate with the computer game,wherein the computer game is configured to: receive data from the atleast one of the plurality of active physical play pieces; based atleast in part on the data received, assist the computer game to infer ashape of a path formed from the plurality of active physical playpieces; generate a virtual model of a path based on the inferred shapeof the path formed from the plurality of active physical play pieces;and display the virtual model of the path on a display device separatefrom the plurality of active physical play pieces.
 2. The set accordingto claim 1, wherein one or more of the plurality of active physical playpieces in the set is shaped such that it is capable of interlocking withone or more other ones of the active physical play pieces or passivephysical play pieces.
 3. The set according to claim 1, wherein two ormore of the plurality of active physical play pieces have differentshapes.
 4. The set according to claim 1, wherein the at least one of theplurality of active physical play pieces comprise a wirelesstransmitter.
 5. The set according to claim 1, wherein one or more of theplurality of the active physical play pieces in the set comprises: awireless receiver arranged to receive commands from the computer game.6. One or more computer storage media with device-executableinstructions that, when executed by a computing system, direct thecomputing system to: determine a physical arrangement of a plurality ofphysical play pieces; infer a virtual model of a path from thearrangement, wherein within gameplay, a virtual object is constrained tothe virtual model of the path; and display the virtual model of the pathon a display device separate from the plurality of physical play pieces,wherein the plurality of physical play pieces comprises at least one ormore active physical play pieces and at least one or more passivephysical play pieces, and wherein at least one of the active physicalplay pieces comprises one or more sensors configured to detect anarrangement of a proximate passive physical play piece when the passivephysical play piece is proximate to the at least one active physicalplay piece, and wherein the passive physical play pieces do not comprisea sensor.
 7. The computer storage media according to claim 6, whereinthe virtual model of the path is based on both the physical arrangementof the plurality of physical play pieces and a shape of each of theplurality of physical play pieces.
 8. The computer storage mediaaccording to claim 6, wherein the virtual model of the path is based ona spacing between the plurality of physical play pieces.
 9. The computerstorage media according to claim 6, wherein the device-executableinstructions that, when executed by the computing system, direct thecomputing system to determine the physical arrangement of the pluralityof physical play pieces comprises: device-executable instructions that,when executed by the computing system, direct the computing system toreceive configuration data from one or more physical play pieces. 10.The computer storage media according to claim 6, wherein thedevice-executable instructions that, when executed by the computingsystem, direct the computing system to determine a physical arrangementof the plurality of physical play pieces comprises: device-executableinstructions that, when executed by the computing system, direct thecomputing system to sense an arrangement of the plurality of physicalplay pieces.
 11. The computer storage media according to claim 6,wherein the device-executable instructions, when executed by thecomputing system, further direct the computing system to: generate agraphical user interface reflecting a configuration of at least aportion of the path to the user.
 12. The computer storage mediaaccording to claim 6, wherein the device-executable instructions, whenexecuted by the computing system, further direct the computing systemto: generate a graphical user interface showing a virtual model of thevirtual object and at least a portion of the virtual model of the path.13. The computer storage media according to claim 6, wherein thearrangement of the plurality of physical play pieces is user generated.14. The computer storage media according to claim 6, wherein thedevice-executable instructions, when executed by the computing system,further direct the computing system to: present an objective to a userwithin a game; and modify gameplay dependent upon whether the objectiveis met.
 15. The computer storage media according to claim 14, whereinthe objective defines a target arrangement of the plurality of physicalplay pieces and/or a target location of the virtual object.
 16. Thecomputer storage media according to claim 6, wherein the virtual objectis associated with a physical object.
 17. A play system comprising acomputer game and a plurality of active physical play pieces, whereinthe active physical play pieces are arranged to actively communicatewith at least one of each other and assist the computer game to generatea virtual path by inferring a shape of a physical path formed from theactive physical play pieces, wherein the computer game is arranged toreceive data from one or more of the active physical play pieces and toinfer the shape of the physical path based on the data received, whereinwithin gameplay at least a portion of the virtual path is displayed on auser interface display separate from the active physical play pieces,wherein a virtual object is constrained to an inferred virtual path,wherein the play system further comprises a plurality of passivephysical play pieces, wherein the passive physical play pieces are notcapable of receiving or sending data to or from other physical playpieces or the computer game, and wherein one or more of the activephysical play pieces comprise one or more sensors configured to detectan arrangement of a proximate passive physical play piece when thepassive physical play piece is proximate to the active physical playpiece.